1. Field of the Invention
The present invention relates to a method utilized in a wireless communication and communication device thereof, and more particularly, to a method of handling security configuration in a wireless communication system and communication device thereof.
2. Description of the Prior Art
In a mobile communication system, information security technologies are employed to protect signalling and user plane messages from eavesdropping and malicious modification. The information security is typically achieved by using encryption and integrity protection mechanisms, which rely on various keys, counters, etc. In an EPS (Evolved Packet Subsystem) system including a long term evolution (LTE) radio access system and a EPC (Evolved Packet Core) system, a user equipment (UE) maintains security context, including keys, ciphering/integrity protection algorithms, key derivation functions, etc, for realizing UP (User Plane), NAS (Non Access Stratum) and AS (Access Stratum) protection.
For security continuity on intra/inter-system mobility, e.g. a handover or connection re-establishment, two types of security contexts are defined: Cached security context and Mapped security context. The cached security context is created for a given system during prior access. For example, an authentication and key agreement (AKA) procedure over an E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) is used to generate an intermediate key KASME which is shared between the UE and an access security management entity, i.e. a MME (Mobility Management Entity), based on a permanent key K and EPS ciphering/integrity keys (CK/IK). The KASME is associated with the cached security context of the LTE system.
In contrast, the mapped security context is created by converting the currently-used security context for a target system in inter-system mobility. For example, a UE performing a handover from a UMTS to the LTE system creates mapped security context by deriving EPS keys from UMTS keys. More specifically, an intermediate key K′ASME, associated with the mapped security context, is derived from CK/IK derived from a UMTS AKA procedure with the help of a one-way key derivation function.
In an intra-LTE handover following a handover to E-UTRAN, a keyChangeIndicator information element (IE) in a RRCConnectionReconfiguration message is utilized to indicate whether the UE should use the keys associated with the latest available intermediate key KASME. If the keyChangeIndicator IE is set to ‘TRUE’, the UE updates a KeNB key (base-station-level key) based on the latest available KASME key, or else the UE updates the KeNB key based on the intermediate KASME key to which the current KeNB is associated. Thus, the UE always updates the KeNB key based on the cached security context (KASME) in the intra-LTE handover procedure for the AS and NAS transmission protection. In addition, the UE has to update the KeNB key based on the KASME key to which the current KeNB is associated when receiving the RRCConnectionReconfiguration message.
In a RRC (Radio Resource Control) connection re-establishment procedure (e.g. triggered by a radio link failure) following a handover to E-UTRAN, a keyChangeIndicator information element (IE) in a RRCConnectionReestablishment message is utilized to indicate whether the UE should use the keys associated with the latest available intermediate key KASME. If the keyChangeIndicator IE is set to ‘TRUE’, the UE updates a KeNB key (base-station-level key) based on the latest available KASME key, or else the UE updates the KeNB key based on the intermediate KASME key to which the current KeNB is associated. Thus, the UE always updates the KeNB key based on the cached security context (KASME) in the RRC connection re-establishment procedure for the AS and NAS transmission protection. In addition, the UE has to update the KeNB key based on the KASME key to which the current KeNB is associated when receiving the RRCConnectionReestablishment message.
On the other hand, the MME, for a successful handover from the UTRAN to E-UTRAN, derives the intermediate key K′ASME from the CK/IK of the UMTS system with the help of an one-way key derivation function. Then, the MME derives NAS keys and the KeNB from the intermediate key K′ASME. In other words, the MME uses the mapped security context to perform NAS message transmission with the UE after the handover.
As can be seen from the above, the UE and MME may apply different types of security context for signaling and data transmission due to the RRC connection re-establishment procedure (e.g. triggered by radio link failure) following an inter-system handover, resulting in data/signaling ciphering/integrity protection errors.
Take a first example. A UE is requested to perform an inter-system handover to an eNB (evolved Node-B) in a E-UTRAN. The UE and MME both derive an intermediate key K′ASME (mapped security context) from CK and IK used in the source system. In addition, the UE also derives a key KeNB from the intermediate key K′ASME and uses the key KeNB to derive ciphering and integrity keys, such as KUPenc, KRRCint and KRRCenc, for security activation. As a result, the derived KeNB is associated to the K′ASME key. In addition, the UE has cached EPS security context including intermediate key KASME. After the inter-system handover, the eNB requests the UE to perform an intra LTE handover to a target eNB. During the intra LTE handover, the MME uses the intermediate key K′ASME to derive the KeNB and sends the KeNB to the target eNB. In addition, in the intra-LTE handover, the corresponding keyChangeIndicator IE is set to ‘FALSE’. According to the prior art, the UE has to use an intermediate key KASME to which the current KeNB is associated, for updating the KeNB key. However, the KASME to which the current KeNB is associated does not exist in the UE because the current KeNB is associated to the intermediate K′ASME key. The UE may use the intermediate KASME of the cached EPS security context to update the key KeNB, causing KeNB content difference between the UE and the target eNB. Different keys KeNB cannot derive the same CK and IK. As a result, the UE and the target eNB use different ciphering and integrity keys for signaling and data transmission, resulting in transmission failure after the intra-LTE handover.
Take a second example. A UE is requested to perform an inter-system handover to an eNB (evolved Node-B) in a E-UTRAN. The UE and MME both derive an intermediate key K′ASME (mapped security context) from CK and IK used in the source system. In addition, the UE also derives a key KeNB from the intermediate key K′ASME and uses the key KeNB to derive ciphering and integrity keys, such as KUPenc, KRRCint and KRRCenc, for security activation. In addition, the UE has cached EPS security context including intermediate key KASME. The inter-system handover command can include the keyChangeIndicator IE. How to interpret the keyChangeIndicator IE for the inter-system handover is not specified for the UE. If the UE interprets the keyChangeIndicator IE as the intra-LTE handover case, the UE encounters the same problem described in the above example.
Take a third example. A UE is requested to perform an inter-system handover to an eNB in a E-UTRAN. The UE and MME both derive an intermediate key K′ASME (mapped security context) from CK and IK used in the source system. In addition, the UE also derives a key KeNB from the intermediate key K′ASME and uses the key KeNB to derive ciphering and integrity keys, such as KUPenc, KRRCint and KRRCenc, for security activation. As a result, the derived KeNB is associated to the intermediate key K′ASME. In addition, the UE has cached EPS security context including intermediate key KASME. The UE performs a RRC connection re-establishment procedure to a target eNB due to radio link failure. According to the prior art, the UE uses the KASME to which the current KeNB is associated when receiving a RRCConnectionReestablishment message. However, the current intermediate key KASME is not associated to the current KeNB that is associated to the intermediate key K′ASME. The UE possibly uses the intermediate key KASME of the cached EPS security context to update the key KeNB. However, the MME has used the intermediate key K′ASME to derive the key KeNB and sends the KeNB to the target eNB during the RRC connection re-establishment procedure. As a result, the UE ciphering keys and integrity keys are different from eNB ciphering keys and integrity keys, resulting in failure of the RRC connection re-establishment procedure.
Furthermore, an integrityProtAlgorithm IE used to indicate an algorithm for integrity protection of the SRBs (Signaling Radio Bearer) is an optional IE. The cipheringAlgorithm IE used to indicate an algorithm for ciphering the SRBs and DRBs (Data Radio Bearers) is also an optional IE. The prior art does not specify how to handle a case that the integrityProtAlgorithm or cipheringAlgorithm IE is missed (not included) in a received message, such as a securityConfiguration message. Without this, the UE and the network may use different algorithms to derive corresponding keys, thereby causing data/signaling ciphering/integrity protection errors.